Deliverables Due for CS 440 Fall 2016

The following table outlines exactly what is due when for each half-project this semester.

Specific details for each assignment follow the table.

Last updated 19 January 2016

Assignment Details

In chronological order of first occurance

Group Assignment Questionnaire

• Complete and submit by the end of class the second week of classes.
• Hard copy preferred.
• If you need to resubmit a revised version, label it clearly as an updated revision ( with a date. )

Seting up and Using iceScrum

• See the Getting Started With iceScrum document for more information.
• All group members should have accounts
• A project should be created with all team members added.
• Release and Sprint dates should be configured properly according to the given schedule.
• Preliminary stories should be created, with some assigned to sprints.
• Tasks should be created, with at least one task assigned to each team member.
• iceScrum task lists should be updated regularly, at least before every new sprint.
• iceScrum records may be used to verify project participation.

Scenarios

• Describe in a narrative fashion what will happen at the next scheduled demo
• Follow the file naming and formatting guidelines for scenarios.
• See the samples provided on the project resources page and discussed in class.
• Add as a document to your git repository and iceScrum site no later than the listed deadline.
• Hand in a printed hard copy at the beginning of class.

Project Description Document

• Find the project report template on the project resources page.
• Complete the first 8 sections of the template provided. ( I.e. all of part I )
• Remove instructions, etc. from the template ( first 8 sections only for now. Remove from other sections as they are completed. )
• If you have information for the later sections of the document, e.g glossary, bibliography, ideas for solutions, etc., go ahead and add them in whenever they become available.
• The theme of the development projects for this semester is "Location-Based Games".
  • The general idea is to develop a game in which the player's location, either in the real-world or in the game-world is important.
  • Examples:
  • Pokemon Go - Using a device equipped with GPS, players must move about in the real world in order to play the game and achieve objectives. Some plays require the user to go to a specific location, others just require that the player move around.
  • Geocaching - Players must go to specific coordinates in the real world, where they find caches of small physical treasures. In general they take one of the treasures and leave a small token of their own in exchange, so the contents of the caches change over time.
  • Where in the World is Carmen San Diego? - Players take on the role of a detective chasing a suspect around the world, following clues from one location to the next. Players must know some geography and world culture in order to follow the clues, such as "The suspect has gone to watch a river being dyed green in celebration of Saint Patrick's Day".
  • Journey Through Europe / Scotland Yard - These board games involve players traveling from place to place across Europe / London
  • The games may not be exact implemenations or trivial variations of existing games, though you may get ideas from existing games.
  • No violent, offensive, or first-person shooter games please. If you have any questions, please ask.
  • Educational games, in which players either learn from the game or benefit from having knowledge of geography, etc. are encouraged.
  • Your project will need to be complex and significant enough that it will require a team to develop it, so think big. Do not limit yourself to what a group of students can get done in a single semester, and certainly develop something beyond the abilities of a single programmer working alone. ( You may want to think about possible subsystems, such as an overall gameplay controller, a communications subsystem, the AI logic for non-player characters, perhaps a module that would access real-world data in real time, etc. )

Two-Page Summaries

• Each major project report ( Project Description, Requirements & Test Plans, Final Report, and Unit Test & Inspection Report ) must be accompanied by a separate two-page summary.
• Follow the file naming and formatting guidelines.
• Summaries should be separate documents from their corresponding reports.
• Don't report on the work that you did or how you spent your time. Report instead on the results of that work. I.e. discuss the deliverables not the efforts required to generate them.
• Hand in summaries both electronically via git and as a hardcopy in class.
• The Requirements & Test Plan summary should include a brief ( 1 to 2 sentence ) paragraph describing the project, and then focus primarily on the requirements and test plans.
• The Final Project summary should summarize the entire final document, including description, requirements, test plans, and designs.

Oral Presentations

• Each major project report ( description, requirements & test plans, and the final report ) will be presented with a nominal 5-minute Powerpoint presentation.
• E-mail your presentations to jbell@uic.edu no later than the assigned deadline, and also upload a copy to your git repository.
• Please make sure to include "CS 440" and your group number in the subject of the e-mail, and include your group number and a descriptiove title in the file name of your presentation.
• ( Hint: If you save your presentation as a PowerPoint "show", it will launch directly without going through the PowerPoint program. )
• Full attendance is required on all presentation days, whether your group is presenting or not. Everyone should be prepared to present on the first presentation day of the week, and must attend the rest of the week even after having made their presentation.
• It is not required that all members speak during the presentation, but all members must be present and prepared to answer quesitons.
• Please no open laptops, discussions, or other activities during student presentations - Give the speakers your attention.
• The requirements & test plan presentation should have only a very brief ( 1 slide ) description of the project.
• The final presentaiton should cover the entire semester's work, with emphasis on the final system design. ( Students from future semesters will be invited to the final semester presentations, and they will also be recorded for future student to watch at a later date. )

Presentation Evaluations

• As you watch oral presentations you will be asked to evaluate what you see, and to provide feedback to the speaker(s) on forms provided.
  • Sample Form
• The main purpose of this is to aid the speakers in giving better presentations in the future.
• Your comments will be given anonymously to the presenters. Your comments will not affect their grade.
• You will be given a grade based on how completely you fill out the form, not on the "accuracy" of your comments.
  • In order to get full credit you must provide at least one compliment and at least one suggestion for improvement for each presentation ( other than your own ), as well as circling scores.
  • There will not be a lot of points involved, and most students should get full credit most of the time, but they will add up if you do not fully participate.

Coding Demonstrations ( to TA )

• The TA will post a schedule of demonstration time slots, nominally 15 minutes each, and instructions for how to sign up for a slot.

• The purpose of the demonstrations is to show how well your product conforms to the scenario you wrote earlier, and how well your group has worked together to accomplish the task.
• It is not necessary that all members speak, but all members must be present and prepared to answer questions.

( Midterm ) Exams

• All exams will be cumulative, with emphasis on material not covered on previous exams.
• To the extent possible, all material covered in class, all assigned reading, and all material covered in project work will be covered on the exams.
• All exams are closed book and closed notes.
• Format will most likely include a mix of multiple-choice questions and practical implementation. There is not likely to be an essay type component.

Requirements & Test Plans Document

• Extend your previous ( description ) report by completing sections II and IV.
  • Section II consists of the requirements for your project
  • Section IV are the acceptance test plans needed to determine whether or not the requirements have been met.
• Correct any deficiencies identified in your previous report.
• Create a two-page summary as a separate document. ( See above. )

Unit Test & Inspection Report

• This document reports the results of the unit testing and inspection sprint for the coding project.
• Each team member should have some significant code to be tested and inspected.
• Each team member submits ( some of ) their code to the rest of the group to be inspected.
  • Each team member then serves on the inspection team for each of the remaining team members.
  • So for example if there are four members on a team, then there must be four ( significant ) pieces of code to be inspected, each authored by a different member of the team and each inspected by the remaining three team members. ( Each team member will need to inspect three different code submissions. )
• Each team member must also develop and execute unit tests for ( some of ) their code.
  • This code may be the same code that was submitted for inspection, but it does not have to be.
• Create a two-page summary as a separate document. ( See above. )

Coding Demonstrations ( to Class )

• Each group will have approximately five minutes of class time to demonstrate the results of their coding project.
• A brief description of the project is appropriate, but the majority of the time should be spent demonstrating the working program.
• Demos must run in the classroom environment, either on the classroom computer or using your own laptop.
• Any materials you need pre-loaded on the classroom computer should be loaded before class, e.g. the night before or early in the morning. Any materials you need the instructor to load must be e-mailed no later than midnight the night before.

Final Report

• The final version of the development project should have all ( relevant ) sections completed.
• Correct any deficiencies found in earlier versions.
• The corresponding two-page summary should summarize the entire report, not just the new sections.
• Submit both the final report and two-page summary via git no later than midnight on Friday of the last day of classes.

Final Presentations

• The target audience for the final project presentations are students who take this course in the future, and who would be implementing your projects.
• All sections should be covered, but description, requirements, and test plans should be brief, perhaps one or at most two slides each.
• Emphasis should be on the final system design, including subsystems, classes, and their relationships.
• Don't put in so much detail that your diagrams are unreadable. For example class diagrams should probably show only the names of the classes and not any internal details, unless focusing on a single class.
• Presentations will be recorded for future review, so be sure to use the microphone provided.